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Abstract 

FLUX is a programming method for the design of agents that reason logically about 
their actions and sensor information in the presence of incomplete knowledge. The core 
of FLUX is a system of Constraint Handling Rules, which enables agents to maintain an 
internal model of their environment by which they control their own behavior. The general 
action representation formalism of the fluent calculus provides the formal semantics for the 
constraint solver. FLUX exhibits excellent computational behavior due to both a carefully 
restricted expressiveness and the inference paradigm of progression. 



1 Introduction 

One of the most challenging and promising goals of Artificial Intelligence research 
is the design of autonomous agents, including robots, that explore partially known 
environments and that are able to act sensibly under incomplete information. To 
attain this goal, the paradigm of Cognitive Robotics ULesperance et al. 1994| ) is to 
endow agents with the high-level cognitive capability of reasoning. Exploring their 
environment, agents need to reason when they interpret sensor information, mem- 
orize it, and draw inferences from combined sensor data. Acting under incomplete 
information, agents employ their reasoning facilities for selecting the right actions. 
To this end, intelligent agents form a mental model of their environment, which 
they constantly update to reflect the changes they have effected and the sensor 
information they have acquired. 

Having agents maintain an internal world model is necessary if we want them 
to choose their actions not only on the basis of the current status of their sensors 
but also on the basis of what they have previously observed or done. Moreover, 
the ability to reason about sensor information is necessary if properties of the 
environment can only be observed indirectly and require the agent to combine 
observations made at different stages. 

While standard programming languages such as Java do not provide general rea- 
soning facilities for agents, logic programming (LP) constitutes the ideal paradigm 
for designing agents that are capable of reasoning about their actions IjShanahan 1997|l . 
Examples of existing LP-systems that have been developed from general action the- 
ories are GOLOG JLevesaue et al. 19971 IReiter 2001all. based on the situation cal- 
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cuius ( [McCarthy 1963| ), or the robot control language developed in IjShanahan and Witkowski 2000|l . 
based on event calculus ( |Kowalski and Sergot 1986t . However, a disadvantage of 
both these systems is that knowledge of the current state is represented indirectly 
via the initial conditions and the actions which the agent has performed up to now. 
As a consequence, each time a condition is evaluated in an agent program the en- 
tire history of actions is involved in the computation. This requires ever increasing 
computational effort as the agent proceeds, so that this concept does not scale up 
well to long-term agent control. 

Having an explicit state representation as a fundamental concept, the fluent cal- 
culus l|Thielscher 1999|l offers an alternative theory as the formal underpinnings for 
a high-level agent programming method. In this paper, we present the logic pro- 
gramming method FLUX (for: Flu ent Executor) for the design of intelligent agents 
that reason about their actions using the fluent calculus. A constraint logic program, 
FLUX comprises a method for encoding incomplete states along with a technique 
of updating these states according to a declarative specification of the elementary 
actions and sensing capabilities of an agent. Atomic state knowledge is encoded in 
a list with a tail variable, which signifies the incompleteness of the state. Nega- 
tive and disjunctive state knowledge is encoded by constraints. We present a set of 
Constraint Handling Rules (CHRs) (|Friihwirth 1998|l for combining and simplifying 
these constraints. In turn, these rules reduce to standard finite domain constraints 
when handling variable arguments of individual state components. Appealing to 
their declarative interpretation, our CHRs are verified against the foundational 
axioms of the fluent calculus. 

With its powerful constraint solver, the underlying FLUX kernel provides gen- 
eral reasoning facilities, so that the agent programmer can focus on specifying the 
application domain and designing the high-level behavior. Allowing for concise pro- 
grams and supporting modularity, our method promises to be eminently suitable 
for programming complex strategies for artificial agents. Thanks to a restricted ex- 
pressiveness and a sound but incomplete inference engine, reasoning in FLUX is 
linear in the size of the internal state representation. FLUX therefore exhibits ex- 
cellent computational behavior. Thanks to the progression principle, FLUX scales 
up particularly well to long-term control. 

The paper is organized as follows: In Section we recapitulate the basic no- 
tions and notations of the fluent calculus as the underlying theory for an LP-based 
approach to reasoning about actions. In Section |2| we present a set of CHRs for 
constraints expressing negative and disjunctive state knowledge. We prove their 
correctness wrt. the foundational axioms of the fluent calculus. In Section 01 the 
constraint solver is embedded into a logic program for reasoning about actions, 
which, too, is verifled against the underlying semantics of the fluent calculus. In 
Section we integrate state knowledge and sensing into FLUX. An example of a 
FLUX agent program is given in Section [HI in which we also present the results 
of experiments showing the computational merits of our approach. We conclude in 
Section 

The constraint solver, the general FLUX system, and the example agent program 
are available for download at our web site www.fluxagent.org. 
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Fig. 1. Layout of a sample ofRce floor and a scenario in which four oflices are 
occupied. In the right hand side, the locations are depicted in which the robot 
senses light. 



2 Reasoning about states and sensor input with the fluent calculus 

Throughout the paper, we will use the following example of an agent in a dynamic 
environment: Consider a cleaning robot which, in the evening, has to empty the 
waste bins in the hallway and rooms of the floor of an office building. The robot 
shall not, however, disturb anyone working in late. It is equipped with a light 
sensor which is activated whenever the robot is adjacent to a room that is occupied, 
without indicating which direction the light comes from. An instance of this problem 
is depicted in Figure^ The robot can perform three basic actions, namely, cleaning 
the current location, turning clockwise by 90 degrees, and moving forward in the 
current direction to the adjacent cell. Our task is to program the "cleanbot" to 
empty as many bins as possible without risking to burst into an occupied office. This 
problem illustrates two challenges raised by incomplete state knowledge: Agents 
have to act cautiously, and they need to interpret and logically combine sensor 
information acquired over time. 

The fluent calculus is an axiomatic theory of actions that provides the formal un- 
derpinnings for agents to reason about their actions l|Thielscher 1999|l . Formally, it 
is a many-sorted predicate logic language which includes the two standard sorts of a 
FLUENT (i.e., an atomic state property) and a state. For the cleaning robot domain, 
for example, we will use these four fluents (i.e., mappings into the sort fluent): 
At{x, y), representing that the robot is at {x, y); Facing{d) , representing that the 
robot faces direction d G {1, ... ,4} (denoting, respectively, north, east, south, and 
west); CJeaned(2;, 2/), representing that the waste bin at {x,y) has been emptied; 
and Occupied{x , y) , representing that {x,y) is occupied. We make the standard 
assumption of uniqueness-of-names, UNA[At, Facing, Cleaned, Occupied] . ^ 

States are built up from fluents (as atomic states) and their conjunction, using 



1 Following iBaker 19891 . UNA[hi, ...,hn] =' A^^j hi{x) ^ hj{y) A A,[^i{^) = h,{y) D x = y]. 
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the binary function o : state x state i— > state along with the constant : state 
denoting the empty state. For example, the term At(l, l)o[Facing{l)oz) represents 
a state in which the robot is in square (1,1) facing north while other fluents may 
hold, too, summarized in the variable sub-state z. ^ 

A fundamental notion is that of a fluent / to hold in a state z. For notational 
convenience, the macro Holds{f, z) serves as an abbreviation for an equational 
formula which says that z can be decomposed into / and some state z' : 

Holdsif, z) (32') z=foz' (1) 

This dcflnition is accompanied by the following foundational axioms of the fluent 
calculus, which ensure that a state can be identified with the fluents that hold in 
it. 



Definition 1 

Assume a signature which includes the sorts fluent and state such that fluent 
is a sub-sort of state, along with the functions o,0 of sorts as above. The foun- 
dational axioms Sstato of the Quent calculus are: 

1. Associativity and commutativity, 

(21 o 22) o 23 = 21 o (22 o 23) 

2l O 22 = 22 O 2l 

2. Empty state axiom, 

^Holdsif, (H) (3) 

3. Irreducibility and decomposition, 

HoldsihJ) D /i -/ (4) 
Holds (/ , 21 o 22 ) D Holds (/ , 21 ) V Holds (/ , 22 ) (5) 

4. State equivalence and existence of states, 

(V/) (Holdsif, 21) = Holdsif, 22)) D 21 = 22 (6) 
(VP)(32)(V/) iHoldsif, 2) ^ Pif)) (7) 

where P is a second-order predicate variable of sort fluent. 

Axioms ©^ISl) essentially characterize "o" as the union operation with as the 
empty set of fluents. Associativity allows us to omit parentheses in nested appli- 
cations of "o". Axiom © says that two states are equal if they contain the same 



^ A word on the notation: Predicate and function symbols start with a capital letter while variables 
are denoted by lowercase letters, possibly with sub- or superscripts. Function "o" is written 
in infix notation. Throughout the paper, free variables in formulas are assumed universally 
quantified. Variables of sorts fluent and STATE shall be denoted, respectively, by the letters / 
and z . 
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fluents, and second-order axiom ^ guarantees the existence of a state for any 
combination of fluents. 

The foundational axioms of the fluent calculus can be used to draw conclusions 
from incomplete state specifications and acquired sensor information. Consider, e.g., 
the definition of what it means for our cleaning robot to sense light at a location 
{x, y) in some state z: 

Light{x,y,z) = 

Holds {Occupied{x + 1, y), z) V Holds{Occupied{x , y + 1), z) (8) 
V Holds{Occupied{x — 1, y), z) V Holds{Occupied{x , y ~ I), z) 

Suppose that at the beginning the only given unoccupied locations are: the home 
square of the robot (axiom below), the squares in the hallway (axiom Ullfl 
below) and any location outside the boundaries of the office floor (axioms (|12|l . (|13(l 
below). Suppose further that the robot already went to clean (1,1), (1,2), and 
(1, 3), sensing fight in the last square only (cf. Figure^). Thus the current state, 
satisfies 

C = At{l, 3) o Facing(l) o Cleaned{l, 1) o Cleaned{l, 2) o aeaned(l, 3) o z (9) 



for some z, along with the following axioms: 

^ffoWs(Occupied(l,l),z) (10) 

-.HoWs(Occupied(l,2),2) A ... A -^Holds{Occupied{4,5), z) (11) 

(Vx) {^Holds{Occupied{x, 0), z) A -^Holds{Occupied(x , 6), z)) (12) 

(Vy) {^Holds{Occupied{0, y), z) A -^Holds{Occupied{Q , y), z j) (13) 

-Ligit(l,2,C) (14) 

LigM(l, 3,0 (15) 



From (HH) and (jEJ it follows -iJfoJds(Occupied(l, 3), C) • With regard to ©, the 
foundational axioms of decomposition ^ and irreducibility along with the 
axiom of uniqueness-of-names imply 

^Holds{Occupied{l, 3), z) 

On the other hand, 1151) and JSJ imply 

Holds{Occupicd{2, 3), C) V Holds{Occupied{l, 4), C) 

V Holds{Occupicd{0, 3), C) V Holds {Occupied{l, 2), C) 

Again with regard to Q , the foundational axioms of decomposition and irreducibil- 
ity along with the axiom of uniqueness-of-names imply 

Holds{Occupied{2, 3), z) V Holds{Occupied{l, 4), z) 

V Holds{Occupied{0, 3), z) V Holds{Occupied{l, 2), z) 

^ A remark for readers who are familiar with early papers on the fluent calculus: 
The original solutio n to the frame problem in this calculus required function "o" to 
be non-idempotent jHolldobler and Schneeberger 1990 1, so that, e.g., Occupied {2, 3) ^ 
Occ\ipied{2,J>) o OccnpiediT,,^) . Since this is against the intuition of "o" as a reified logical 
conjunction, the new axiomatization, first used in jThiclschcr 2001), is no longer based on 
non-idempotence. In fact, foundational axiom JHJ along with jSJ and associativity implies that 
z o z = z for any z . 
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From and (^TJ it follows that 

Holds{Occupied{2,3), z) V Holds{Occupied{l,4), z) (16) 

This disjunction cannot be reduced further, that is, at this stage the robot cannot 
decide whether the light in (1,3) comes from office (2,3) or (1,4) (or both, for 
that matter). Suppose, therefore, the cautious cleanbot goes back, turns east, and 
continues with cleaning (2, 2) , which is a hallway location and therefore cannot be 
occupied according to 11111 . Sensing no light there (cf . Figure ^ , the new state is 

C = At{2, 2) o Facmg(2) o 

Cleaned{l, 1) o Cleaned{l, 2) o Cleaned{l, 3) o Cleaned{2, 2) o z 

for some z that satisfies (fTT) | - ((K^ and (fT?)|l . We also know that -^Light{2,2, (') . 
From JHJ, -^Holds{Occupied{2, 3), (') ; hence, decomposition and irreducibility along 
with the axiom of uniqueness-of-names imply -iifo]ds(Occupied(2, 3), 2); hence, 
from (|16|l it follows JfoWs(Occupied(l, 4), z), that is, now the robot can conclude 
that (1,4) is occupied. 



3 A constraint solver for the fluent calculus 

The axiomatic fluent calculus provides the formal underpinnings for an LP-based 
approach to reasoning about incomplete state specifications. To begin with, in- 
complete states are encoded by open-ended lists of fluents (possibly containing 
variables) : 

Z = [Fl, . . . ,Fk I _ ] 

It is assumed that the arguments of fluents are encoded by integers or symbolic 
constants, which enables the use of a standard arithmetic solver for constraints on 
partially known arguments. Negative and disjunctive state knowledge is expressed 
by the following state constraints: 

constraint semantics 



not_liolds(F,Z) ^Holds{f,z) 

not_holds_all(F,Z) (Va;) -^Holds{f, z) , x variables in / 

or_holds([Fl, . . . ,Fn] ,Z) y"^^ Holds {f.„ z) 

These state constraints have been carefully designed so as to be sufficiently expres- 
sive while allowing for efhcient constraint solving. An auxiliary constraint, written 
duplicatejfree(Z), is used to stipulate that a list of fluents contains no multiple 
occurrences. As an example, the following clause encodes the specification of state C 
of Section 121 (cf. axioms iP)-l(T^1: 

zeta(Zeta) :- 

Zeta = [at(l,3) ,facing(l) ,cleaned(l,l) ,cleaned(l,2) ,cleaned(l,3) I Z] , 
not_holds(occupied(l, 1) , Z) , 

not_holds(occupied(l,2) , Z) , not_holds(occupied(4,5) , Z) , 

not_holds_all(occupied(_,0) , Z) , not_holds_all(occupied(_,6) , Z) , 
not_holds_all(occupied(0,_) , Z) , not_holds_all(occupied(6,_) , Z) , 
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light (1, 2, false, Zeta), light (1, 3, true, Zeta). 

The auxiliary predicate Light(x, y,p, z) defines under what circumstances there is 
hght {p — True) or no hght {p = False) in state z at square {x, y) (cf. axiom (jSJ). 

light (X, Y, Percept, Z) :- 

XE #= X+1, XW #= X-1, YN #= Y+1, YS #= Y-1, 
( Percept = false, 

not_holds(occupied(XE,Y) , Z) , not_holds(occupied(X,YN) , Z) , 
not_holds(occupied(XW,Y) , Z) , not_holds(occupied(X,YS) , Z) 
; Percept = true, or_holds( [occupied (XE,Y) , occupied (X,YN) , 

occupied(XW,Y) ,occupied(X,YS)] , Z) ). 

Here and in the foUowing, we use the standard constraint language of finite domains 
(see, e.g., | |Hentenryck 1989| )), which includes arithmetic constraints over the inte- 
gers and symbolic constants, using the equality, inequality, and ordering predicates 
#=, #\=, #<, #> along with the arithmetic functions +, -, *; range constraints (writ- 
ten X: : a. . 6); and logical combinations using #/\ and #\/ for conjunction and 
disjunction, respectively. 

The state constraints are processed using Constraint Handling Rules HFrxihwirth 1998|l . 
The general form of these rules is 

HI, . . . ,Hm <=> Gl, . . . ,Gk I Bl, . . . ,Bn. 

where the head Hi, ... , H„i is a sequence of constraints ( m > 1 ) ; the guard 
Gi,...,Gk is a sequence of Prolog literals {k > 0); and the body Bi,...,Bn 
is a sequence of constraints or Prolog literals (n > 0). An empty guard is omitted; 
the empty body is denoted by True. The declarative interpretation of such a rule 
is given by the formula 

(Va;) (Gl A . . . A Gfe D A . . . A 77™ = {3y) (Bi A . . . A S„)] ) 

where x are the variables in both guard and head and y are the variables which 
additionally occur in the body. The procedural interpretation of a CHR is given 
by a transition in a constraint store: If the head can be matched against elements 
of the constraint store and the guard can be derived, then the constraints which 
match the head are replaced by the body. 



3.1 Handling negation 

Figure|21depicts the first part of the constraint solver, which contains the CHRs and 
auxiliary clauses for the two negation constraints and the constraint on multiple 
occurrences. In the following, these rules are proved correct wrt. the foundational 
axioms of the fluent calculus. 

To begin with, consider the auxiliary clauses, which define a finite domain con- 
straint that expresses the inequality of two fluent terms. By OrNeq, inequality of 
two fluents with arguments ArgX = [Xl, . . . , Xn] and ArgY = [Yl, . . . , Yn] is decom- 
posed into the arithmetic constraint XI 7^ Yl V . . . V Xn ^ Yn. Two cases are distin- 
guished, depending on whether the variables in the first term are existentially or 
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not_holds(_, [] ) <=> true. 7.1 

not_holds(F, [FlIZ]) <=> neq(F,Fl) , not_holds(F,Z) . 7.2 

not_holds_all(_, [] ) <=> true. 7.3 

not_holds_all(F, [FllZ]) <=> neq_all(F,Fl) , not_holds_all(F,Z) . 7.4 

not_holds_all(F,Z) \ not_holds(G,Z) <=> instance (G,F) I true. 7.5 

not_holds_all(F,Z) \ not_holds_all(G,Z) <=> instance (G,F) I true. 7.6 

duplicate_f ree ( [] ) <=> true . 7.7 

duplicate_f ree ( [F I Z] ) <=> not_holds(F,Z) , duplicate_f ree (Z) . 7.8 



neq(F,Fl) :- or_neq(exists,F,Fl) . 

neq_all(F,Fl) :- or_neq(f orall.F.Fl) . 

or_neq(Q,Fx,Fy) :-Fx=.. [F I ArgX] , Fy =. . [GlArgY], 

( F=G -> or_neq(Q,ArgX,ArgY,D) , call(D) ; true ). 

or_neq(_,[],[],(0#\=0)). 
or_neq(Q , [X I XI] , [Y I Yl] ,D) : - 
or_neq(Q,Xl,Yl,Dl) , 

( Q=forall, var(X) -> ( binding (X, XI ,Y1 , YE) -> D=((Y#\=YE)#\/D1) 

; D=D1 ) 

; D=((X#\=Y)#\/D1) ). 

bindingCX, [XllArgX] , [YllArgY] ,Y) :- X==X1 -> Y=Y1 

; binding (X , ArgX , ArgY , Y) . 

Fig. 2. Constraint Handling Rules for the negation constraints and multiple 
occurrences of fluents. The notation HI \ H2 <=> G I B is an abbreviation for 
H1,H2<=>G I H1,B. 



universally quantified. In the latter case, a simplified disjunction is generated, where 
the variables of the first fluent are discarded while possibly giving rise to dependen- 
cies among the arguments of the second fluent. Thus neq_all(f (_, a, _), f (U, V, W)) 
reduces to a ^ V, and neq_all(f (X,X,X),f (U,V,W)) reduces to U 7^ V VV 7^ W. To 
formally capture the universal quantification, we define the notion of a schematic 
fluent / = h{x, r) where x denotes the variable arguments in / and r the 
non-variable arguments. The following observation implies the correctness of the 
constraints generated by the auxiliary clauses. 

Observation 1 

Consider a set of functions into sort FLUENT, a fluent /i = g{ri, . . . ,rm), a 
schematic fluent /2 = g(a;i, . . . , Xfc, rfc+i, . . . , fm), and a fluent / = h{ti, . . . ,t„). 
Let Neq{h,f)=fi^f and iVeqAJJ(/2,/) (V:ei, . . . , a;fc)/2 7^ /, then 



1. if 7^/1, then UNA[J^] \= JVeq(/i,/) and UNA[T] \= NeqAU{f2j); 
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2. ii g = h, then m = n, and UNA[!F] entails 

JVeq(/i,/) = ri ^ ti V . . . V r,„ ^ t„ V 
NeqAll{f2j) = [Vm. U # ij] V rfc+i ^ 4+i V . . . V r„ 7^ t„ V 7^ 

CHRs 1-4 in Figure El by which negation constraints are propagated, are then 
justified — on the basis of their declarative interpretation — by the foundational ax- 
ioms of the fluent calculus. 

Proposition 1 

Foundational axioms Sstatc entail 

1. ^Holds{f,$); and 

2. ^Holdsif,h oz) =f^f,A -Ho7ds(/, z). 
Likewise, if / = g{x, r) is a schematic fluent, then Sstatc entails 

3. (Vf)-ffoWs(/,0); and 

4. {yx)^Holds{f,Aoz) = mf^h A m^Holds{f,z). 

Proof 

Claim 1 follows by the empty state axiom. For claim 2 we prove that Holds{f , fi o z) 
iff / = /i V Holds{f, z). The direction follows by the foundational axioms of 
decomposition and irreducibility. For the "<^=:" direction, suppose f ~ fi, then 
fi° z — f o z, hence Holds{f , fi o z). Likewise, suppose Holds{f, z), then z — f o z' 
for some 2', hence fi o z — fi o f o z' , hence Holds{f ,fi o z). The proof of 3 and 4 
is similar. □ 

CHRs 5 and 6, by which subsumed negative constraints are removed, are correct 
since (Vx) ^ Holds {fi, z) implies both ^Holds{f2,z) and (V^) -iffoids(/2, z), where 
fi is a schematic fluent and /2 is a fluent such that fi6 = /2 for some 9. Finally, 
CHRs 7 and 8 for the auxiliary constraint on multiple occurrences are correct 
since the empty list contains no duplicate elements and a non-empty list contains 
no duplicates iff the head does not occur in the tail and the tail itself is free of 
duplicates. 



3.2 Handling disjunction 

Figure 01 depicts the second part of the constraint solver, which contains the CHRs 
and auxiliary clauses for disjunctive state knowledge. The solver employs an ex- 
tended notion of a disjunctive clause, where each disjunction may include atoms of 
the form Eq{x, y) in addition to fluents. The meaning of such a general disjunctive 
constraint OrHolds{[Si, . . . , 6k], z) is 

w f Holds{f, z) if (5j is fluent / 
y^\x = y if (5j is Eq{x, y) 

This generalization is needed for propagating disjunctions with variables through 
compound states. Consider, as an example, OrHolds{[F{x),F{\)\,[F{y)\z\). This 
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or_holds( [F] ,Z) <=> F\=eq(_,_) I holds (F, Z) . 7.9 

or_holds(V,Z) <=> \+(member(F,V) ,F\=eq(_,_)) I or_and_eq(V,D) , 7.10 

call(D) . 

or_holds(V, [] ) <=> member (F,V,W) , F\=eq(_,_) I or_holds (W, [] ) . 7.11 

or_holds(V,Z) <=> member (eq(X,Y) ,V) , 7.12 
or_neq(exists,X,Y,D) , \+ call(D) I true. 

or_holds(V,Z) <=> member (eq(X,Y) ,V,W) , 7.13 
\+ (and_eq(X,Y,D) , call(D)) I or_holds (W, Z) . 

not_holds(F,Z) \ or_holds(V,Z) <=> member (G,V,W) , 7.14 

F==G I or_holds(W,Z) . 

not_holds_all(F,Z) \ or_holds(V,Z) <=> member (G,V,W) , 715 

instance (G,F) I or_holds(W,Z) . 

or_holds(V, [F|Z]) <=> or_holds (V, [] , [F I Z] ) . 716 

or_holds([Fl|V] ,W, [F|Z]) <=> F1==F -> true ; 717 

F1\=F -> or_holds(V, [FlIW] , [F|Z]) ; 

Fl=. . [_|ArgX] , F=. . LlArgY] , 
or_holds(V, [eq(ArgX, ArgY) ,F1|W] , [F I Z] ) . 
or_holds([] ,W, LIZ]) <=> or_holds(W,Z) . 718 

and_eq([],[],(0#=0)). 

and_eq([X|Xl] , [YlYl] ,D) : - and_eq(Xl , Yl ,D1) , D=( (X#=Y)#/\D1) . 
or_and_eq( [] , (0#\=0)) . 

or_and_eq( [eq(X,Y) lEq] , (Dl#\/D2)) :- or_and_eq(Eq,Dl) , and_eq(X,Y,D2) . 
member (X, [X|T] ,T) . 

member (X, [HIT] , [HI Tl] ) :- member (X, T, Tl) . 



Fig. 3. Constraint Handling Rules for the disjunctive constraint. 



constraint will be rewritten to OrHolds{[Eq{[l], [y]), F{1), Eq{[x], [y]), F{x)], z), in 
accordance with the fact that Sstatc U UNA[F] entails 

Holds{F{x),F{y)o z) V Holds{F {I) , F {y) o z) 

x = y y Holds{F{x),z) V 1 = ?/ V Holds{F{l), z) 

which follows by the foundational axioms of irreducibility and decomposition. 

CHR 9 in Figure 13 simplifies a singleton disjunction according to CHR 10 
reduces a pure equational disjunction to a finite domain constraint. Its correctness 
follows directly from ((T7|) . too. CHR 11 simplifies a disjunction applied to the empty 
state. It is justified by the empty state axiom, which entails 



[HoWs(/,0) V^-] = * 
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for any formula CHRs 12 and 13 deal with disjunctions which include an equality 
which is either true under any variable assignment, or false. If the former, then the 
entire disjunction is true. If, on the other hand, the equality is necessarily false, 
then it is removed from the disjunction. Correctness follows from 

X ^ y D [(f = ?7 V *) = T] and x ^ y D [(f = t/ V = 

The next two CHRs are unit resolution steps: Rule 14 says that if a fluent / does 
not hold, then any disjunction that contains an equal fluent g can be reduced 
by g. Rule 15 generalizes this to universally quantified negation constraints. The 
two CHRs are justified, respectively, by 

-nHolds{f,z) D [{Holdsif , z) V ^) = 4-] 
(Vf ) -^Holdsif, z) D [{Holdslg, z) V ^) = ^ ii fO = g for some 

where x are the variables in /. 

The last group of CHRs, 16-18, encode the propagation of a disjunction through 
a compound state. Informally speaking, each element in the disjunct is compared 
to the head of the state and, if the two are unifiable, the respective equational con- 
straint is introduced into the disjunction. Specifically, with the help of the auxiliary 
ternary constraint OrHolds{v,w^[f\z]), a disjunction is divided into two parts. 
List V contains the fluents that have not yet been evaluated against the head / 
of the state. List w contains those fluents that have been evaluated. Thus the 
meaning of a ternary expression OrHolds{ Ai, A2,[f\ z]) is 

OrHolds{Ai,[f\z]) V OrHolds{ A2, z) (18) 

In the special case that disjunction Ai contains a fluent /i which is identical to 
the head / of the state, disjunction p8(l is necessarily true and, hence, is resolved 
to True by CHR 17. Otherwise, any fluent fi in Ai which does not unify with / 
is propagated without inducing an equality. Any fluent /i which does unify with / 
extends the disjunction by the equality of the arguments of fi and /. Recall, for 
example, the constraint OrHolds{[F{x), F(l)],[F{y)\z]) mentioned earlier, which 
is propagated thus: 

OrHoWs([F(x),F(l)],[F(j/)|z]) 

^ OrHoldsmx),F{l)],[],[F{y)\z]) 

^ OrHolds{[F{l)], [Eq{[x], [y]), F{x)], [F{y)\z]) 

^ OrHolds{[], [Eq([l], [y]), F(l), Eq([^], [y]), F{x)], [Fiy)\z]) 

^ OrHolds{[Eq{[l], [y]), F{l),Eq{[x], [y]), F{x)], z) 

The three rules for propagating a disjunction are justified by the following propo- 
sition, where item 1 is for CHR 16, items 2-4 are for the three cases considered in 
CHR 17, and item 5 is for CHR 18. 

Proposition 2 

Consider a fluent calculus signature with a set of functions into sort fluent. 
Foundational axioms Sstato and uniqueness-of- names UNA[J-] entail each of the 
following, where 5*1 is of the form OrHolds{A, [f\z]) and '^2 is of the form 
OrHolds{A, z): 
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1. *i = [*i V OrHolds{[], z)]; 

2. [Holds{fJoz)\/^i]V^2 = T; 

3. fi^f D i [HoldsifiJ o z) V *i] V ^-2 = *i V [ffoWs(/i, 2) V *2] ); 

4. [HoWs(i^(x), i^(^)o 2) V*i]V*2 = 1'iV[f = y VHoWs(F(f),z)V^'2]; 

5. [OrHoWs([],[/|z]) V ^2] = *2. 

Proo/ 

Claims 1 and 5 are obvious. Claim 2 follows by the definition of Holds. Claims 3 
and 4 follow from the foundational axioms of decomposition and irreducibility along 
with UNA[T]. □ 

3.3 Using the constraint solver 

The constraint solver constitutes a system for automated reasoning about incom- 
plete states and sensor information. As an example, evaluating the specification 
from the beginning of Section |51 results in 

?- zeta(Zeta) . 

Zeta=[at(l,3) ,facing(l) , cleanedCl , 1) ,cleaned(l,2) ,cleaned(l,3) I Z] 
Constraints : 

or_holds( [occupiedd ,4) ,occupied(2,3)] , Z) 

Light at (1,3) thus implies that (1,4) or (2,3) is occupied, but it does not follow 
which of the two. Adding the information that there is no light in (2, 2), the system 
is able to infer that (1,4) must be occupied: 

?- zeta(Zeta) , light(2, 2, false, Zeta) . 

Zeta= [at (1 ,3) ,f acing(l) , cleaned (1 , 1) , cleanedd , 2) , cleanedCl ,3) , 
occupiedd, 4) I Z] 

Constraints : 

not_holds(occupied(2,3) , Z) 

Although the CHRs in the FLUX constraint system are correct, they may not 
enable agents to draw all conclusions that follow logically from a state specification 
if the underlying arithmetic solver trades full inference capabilities for efhciency. 
In standard implementations this is indeed the case, because a conjunction or a 
disjunction is simplified only if one of its equations or disequations is either neces- 
sarily true or necessarily false. As a crucial advantage of these concessions we have 
designed an efficient inference system: The computational effort of evaluating a new 
constraint is linear in the size of the constraint store. 
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holds (F, [F|_]) . 

holds(F,Z) :-nonvar(Z), Z=[F1|Z1], F\==F1, holds(F,Zl). 
holds (F, [F|Z] ,Z) . 

holds(F,Z, [FlIZp]) :-nonvar(Z), Z=[F1|Z1], F\==F1, holds (F, Zl, Zp) . 
minus (Z , [] , Z) . 

minus(Z, [FiFs] ,Zp) :- ( \+ not_holds(F,Z) -> holds(F,Z,Zl) ; 

\+ holds (F,Z) -> Zl = Z ; 

cancel (F, Z, Zl) , not_holds(F,Zl) ), 
minus (Zl ,Fs , Zp) . 

plus(Z, [] ,Z) . 

plus(Z, [FiFs] ,Zp) :- ( \+ holds (F,Z) ->Z1=[F|Z] ; 

\+ not_holds(F,Z) -> Z1=Z ; 

cancel (F, Z, Z2) , Z1=[F|Z2], not_holds(F,Z2) ), 
plus(Zl,Fs,Zp) . 

update(Zl,ThetaP,ThetaN,Z2) :- minus (Zl ,ThetaN,Z) , plus(Z,ThetaP,Z2) . 

Fig. 4. The foundational clauses for reasoning about actions. Auxiliary predi- 
cate Cancel is defined in Figure 



4 Inferring state update in FLUX 

In this section, we embed our constraint solver into a logic program for reasoning 
about the effects of actions based on the fluent calculus. Generalizing previous ap- 
proaches ( |H611dobler and Schneeberger 1990, Bibcl 1986), the fluent calculus pro- 
vides a solution to the fundamental frame problem in the presence of incomplete 
states (|Thielscher 1999|) . The key is a rigorously axiomatic characterization of addi- 
tion and removal of (finitely many) fluents from incompletely specified states. The 
following inductive definition introduces the macro equation zi — i?^ = 22 with the 
intended meaning that state Z2 is state zi minus the fluents in the finite state 'd~ : 

Zl - = 22 == Z2 = Zl 

21 - / = 22 = (^2 = 21 V 22 / = 21) A ^Holds{f, Z2) 
^1 - (/l ° /2 O • ■ • O /n) = 22 (32) (21 - /i = 2 A 2 - (/2 O . . . O /„) = 22) 

The crucial item is the second one, which defines removal of a single fluent / using 
a case distinction: Either zi — f equals 2i (which applies in case Holds (f , zi)), 
or Zl — f plus / equals 21 (which applies in case Holds{f , zi)). 

A further macro 22 = (21 — i?^) + 1?^ means that state 22 is state 21 minus the 
fluents in i?^ plus the fluents in 

22 = (21 - -d-) + 1?+ = {3z) {zi = z A Z2 = zo ■&+) (19) 

where both 19+, i?" are finitely many fluent terms connected by "o". 

Figure 0] depicts a set of clauses which encode the solution to the frame problem 
on the basis of the constraint solver for the fluent calculus. The program culmi- 
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nates in the predicate Update{zi,'3'^ , Z2) , by which an incomplete state zi is 
updated to 22 by positive and negative effects and , respectively, according 
to macro (I19II . The first two clauses in Figure^lencode macro (QJ . Correctness of this 
definition follows from the foundational axioms of decomposition and irrcducibility. 
The ternary Holds{f, z, z') means Holds {f , z) A z' = z — f . The following propo- 
sition implies that the corresponding clauses are correct wrt. the macro definition 
of fluent removal, under the assumption that lists of fluents are free of duplicates. 

Proposition 3 

Axioms Sstatc U {z = /i o A -iHolds{fi, zi)} entail 

Holdsif,z) Az' = z-f = 
/ = A A z' = 

V (3z") (/ ^ A A Holdsif, zi) A z" - zi - / A z' = A ° 

Proof 

We distinguish two cases. 

Suppose f = fi, then Holds{f,z) since z = fi o zi. li z' = z — f , then z' = 
(A ° -^i) — A since z = A ° ^i! hence, z' — zi since -iHoWs(A, zi). Conversely, if 
z' = zi, then z' = (A o zj) - A = z - /. 

Suppose / ^ A- If Holds{f,z) and z' = z — f , then Holds{f,zi) and z' = 
(A ° ^1) ~ / ; hence, there is some z" such that z" = zi — / and z' = A ° 
Conversely, if Holds{f, zi) A z" = zi — / A z' = A ° z", then Holds{f,fi o zi) and 
z' = (A o zi) - /; hence, Holds{f, z) A z' = z - f . □ 

Removal and addition of finitely many fluents is defined recursively in Figure 21 
The recursive clause for Minus says that if -^Holds{f , z) is unsatisfiable (that is, 
/ is known to hold in z), then subtraction of / is given by the definition of the 
ternary Holds predicate. Otherwise, if Holds{f, z) is unsatisfiable (that is, / is 
known to be false in z), then z — / equals z. If, however, the status of the fluent 
is not entailed by the state specification at hand for z , then partial information 
of / in $(z) may not transfer to the resulting state z — / and, hence, needs to 
be cancelled. Consider, for example, the partial state specification 

Holds{F{y),z) A [Holds{F{A), z) Holds{F{B), z)] (20) 

This formula does not entail Holds{F (A) , z) nor -^Holds{F (A) , z) . So what can 
be inferred about the state z — F{A)7 Macro expansion of "— " implies that Testate 
and {(1201} U {zi = z - F{A)} entail -^Holds{F{A), zi). But it does not follow 
whether F{y) holds in zi , nor whether F{B) does, because 

[y^AD ^Holds{F{y),zi)] A 
[y^AD HoldsiFiy),zi)] A 
[^Holds{F{B),z) D ^Holds{F{B),zi)] A 
[Holds{F{B),z) D Holds{F{B),zi)] 

For this reason, all partial information concerning / in the current state z is 
cancelled in the clause for Minus prior to asserting that / does not hold in the 
resulting state. The definition of cancellation of a fluent / is given in FigureElas an 
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cancel (F,Z1,Z2) :- 

var(Zl) -> cancel(F,Zl) , cancelled(F,Zl) , Z2=Z1 

Z1=[G|Z], ( F\=G -> cancel (F, Z, Z3) , Z2= [G I Z3] 

cancel (F,Z,Z2) ). 

cancel (F,Z) \ not_holds(G,Z) <=> \+ F\=G I true, 

cancel (F,Z) \ not_holds_all(G,Z) <=> \+ F\=G I true. 

cancel(F,Z) \ or_holds(V,Z) <=> member (G,V) , \+ F\=G I true. 

cancel(F,Z), cancelled(F,Z) <=> true. 
Fig. 5. Auxiliary clauses and CHRs for cancelling partial information about a fluent. 



extension of our system of CHRs. In the base case, all negative and disjunctive state 
information affected by / is resolved via the constraint Cancel{f,z). The latter 
in turn is resolved by the auxiliary constraint Cancelled{f , z) , indicating that z 
contains no (more) state knowledge which is affected by /.In the recursive clause 
for Cancel{f, zi, 22), each atomic, positive state information that unifies with / is 
cancelled. 

In a similar fashion, the recursive clause for Plus in Figure ^ says that if 
Holds{f , z) is unsatisfiable (that is, / is known to be false in z), then / is added 
to z; otherwise, if ^Holds{f , z) is unsatisfiable (that is, / is known to hold in 2), 
then z + f equals z . If the status of the fluent is not entailed by the state specifi- 
cation at hand for z , then all partial information about / in z is cancelled prior 
to adding / to the state and asserting that / does not hold in the tail. 

The definitions for Minus and Plus imply that a fluent to be removed or added 
does not hold or hold, respectively, in the resulting state. Moreover, cancellation 
does not affect the parts of the state specification which do not unify with the 
fluent in question. Hence, these parts continue to hold in the state resulting from 
the update. The correctness of this encoding of update follows from the macros for 
" — " and "+", which imply that a fluent holds in the updated state just in case it 
either holds in the original state and is not subtracted, or it is added. 

5 Reasoning about actions 

In this section, we extend our basic programming system so as to enable agents to 
reason about what they know and to infer the results of actions involving sensor 
information. Reasoning about knowledge is necessary for agents with incomplete 
information, as they need to select actions according to what they know of the 
state of the environment. The formal concept of state knowledge also allows to 
specify the effects of sensing actions, which, rather than affecting the state itself, 
provide the agent with more information about it. 
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5. 1 Knowledge and sensing in the fluent calculus 

Adopted from the situation calculus ( |McCarthy 1963| ), the two standard sorts 
ACTION and SIT (i.e., situations) are used in the fluent calculus to represent, 
respectively, actions and sequences of actions. Action sequences are rooted in an 
initial situation, usually denoted by the constant 5*0 : SIT. The pre-defined function 
Do : ACTION X SIT 1-^ SIT maps an action and a situation into the situation after the 
action. The function symbol State : SIT i— > state is unique to the fluent calculus 
and links the two key notions of a state and a situation: State(s) denotes the state 
in situation s. 

Inspired by a model of knowledge in the situation calculus ([Moore 1985| |Scherl and Levesque 2003| ), 
the predicate KState : SIT x state has been introduced in (Thielsch er 2000|l . An 
instance KState{s, z) means that, according to the knowledge of the agent, z is a 
possible state in situation s. As an example, recall the initial state of our cleaning 
robot as depicted in Figure ^ For the sake of argument, suppose that the robot 
is told it would perceive light in (1,3). The initial knowledge of the cleanbot can 
then be specified by the following axiom, which defines the knowledge state in 
situation S^: 

iyzo){KState{So,zo) = 

{3z) ( zq = At(l, 1) o Facing(l) o 2 A 

{\fx,y)^Holds{At{x,y),z) A ("id) ^Holds{Facmg{d), z) A 
-iHoJds(Occupied(l, 1), z) A 

-nHolds{Occupied{l,2),z) A ... A ^Holds{Occupied{4:,5),z) A ^ ' 
(Wx) {->Holds{Occupied{x , 0), z) A -^Holds{Occupied{x , 6), z)) A 
(yy) {^Holds{Occupied{0, y), z) A -^Holds{Occupied{6, y), z)) A 
Ligit(l,3,2o))) 

That is to say, initially possible are all states in which the robot is at a unique 
position, viz. (1, 1), facing a unique direction, viz. north (1), and neither (1,1) nor 
any square in the hallway or outside the boundaries can be occupied. The possible 
states are further constrained by the knowledge that there is light at (1,3). On 
the other hand, the agent has no further prior knowledge as to which offices are 
occupied or if any location is cleaned. 

A universal property of knowledge is that it is correct. To this end, a simple 
foundational axiom stipulates that the actual state is always among the possible 
ones: 

Definition 2 

The foundational axioms of the Ruent calculus for knowledge are Sgtatc as in Defi- 
nition ^(cf. Section 0) augmented by 

(ys) KState{s, State{.s)) 

Based on the notion of possible states, a fluent is known to hold in a situation (or 
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not to hold) just in case it is true (false, respectively) in all possible states in that 
situation: ^ 

Knows{f, s) = (Vz) {KState{s, z) D Holds{f, z)) 
Knows{^f,s)''^(\/z){KStatc{s,z)D^Holds{f,z)) 

For example, the axiomatization of the initial knowledge, H21|) . entails that the 
cleanbot knows it is at (1,1) not facing east, that is, 

Sstato U {(EH)} h Knows{At{l,l),SQ) AKnows{^Facing{2),SQ) 

On the other hand, the cleanbot does not know that ofhce (1, 4) is occupied: 

Sstatc U {(EH)} h ^Knows{Occupied{lA),So) 

This is so because there is a possible state zq which satisfies the right hand side of 
the equivalence in (|21|l and in which Occupied{l,4:) does not hold. 

A supplementary macro defines knowledge of a value of a fiuent. An agent has 
this knowledge just in case a particular instance of the fluent in question is known: 

KnowsVal{xJ,s) = {3x) Knows{{3xi) f , s) (23) 

where xi are the variables in / besides x, and Knows{{3xi) f , s) stands for the 
formula {\/ z) {KState{s , z) D {3xi) Holds{f , z)) . For example, the axiomatization 
of the initial knowledge entails that the cleanbot knows which direction it faces, 

^statc U{W h KnowsValid, Facing (d), So) 
On the other hand, although it knows that some office must be occupied, i.e., 

Sstato U {(EH)} h Knows{{3x,y)Occupied{x,y),So) 
the cleanbot does not know which one, 

Sstato U {(EH)} h -^KnowsVal{{x,y),Occupied{x,y),So) 

This is so because there exists a possible state zq which satisfies the right hand 
side of the equivalence in H21() and in which Occupied{l,A) is the only positive 
instance of this fluent; and there also exists a possible state in which a different 
one, viz. Occupied{2^ 3), is the only positive instance of this fluent. 

While the definitions of knowledge by macros ()22(l and H23|l are similar to the 
approach in the situation calculus ( |Scherl and Levesque 2003| ), a crucial difference 
is that the latter defines knowledge in terms of possible situations. To this end, the 
binary relation K{s, s') is used with the intuitive meaning that as far as the agent 
knows in situation s, it could as well be in situation s' . This allows for a nested 
definition of Knows, which provides a form of introspection that is not supported 
in the fluent calculus. On the other hand, the full expressiveness of modal logic is 
computationally demanding. The notion of possible states allows for a straightfor- 
ward and — based on the results of the previous sections — tractable implementation 
of knowledge, which is crucial for practical purposes. We refer to (|Thielscher 200011 
for a more detailed comparison between the two approaches. 

* For the sake of simplicity, we only consider knowledge of fluent literals in this paper; see 
frhielscher 2n00J for the generic extension to knowledge of formulas. 
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knows (F, Z) :- \+ not_holcls(F, Z) . 
knows_not(F, Z) :- \+ holds (F, Z) . 

knows _val(X, F, Z) :- k_holds(F, Z) , \+ nonground(X) . 

k_holds(F, Z) :- nonvar(Z), Z = [FlIZl], 

( instanceCFl, F) , F = Fl ; k_holds(F, Zl) ). 

Fig. 6. Knowledge in FLUX. 



5.2 Inferring knowledge in FLUX 

The concept of knowing properties of the state is essential for the evaluation of 
conditions in agent programs under incomplete information. By definition, a prop- 
erty is known just in case it is true in all possible states. From a computational 
perspective, it is of course impractical to evaluate a condition by literally checking 
every possible state, since there is usually quite a number, often even infinitely 
many of them. Fortunately, our constraint solver provides a feasible alternative. 
Instead of verifying that all states satisfy a property, we can just as well prove 
that the negation of the property is unsatisBable under a given knowledge state. 
This suggests an elegant way of encoding knowledge in FLUX using the principle 
of negation-as-failure. To begin with, a knowledge state KState{a, z) = ^{z) is 
identified with the (incomplete) state specification ^{z). Then a fluent / is known 
in situation a iff the axiom set {^{z),^Holds{f , z)} is unsatisfiable. Likewise, / 
is known to be false in situation a iff {^{z), Holds{f , z)} is unsatisfiable. 

Theorem 1 

Let KState{a, z) = ^{z) be a knowledge state and / a fluent, then 

{KState{a, z) = ^z)} \= Knows{f,a) iff mz),^Holds{f,z)} \= _L 

and 

{KState{a, z) = ^z)} \= Knows{-^f , a) iff {^{z),HoMs{f , z)} ^ _L 

Proof 

{KState{a,z) =^z)} \= Knows{f,a) 

iff {KState{(j, z) = ^{z)} \= (V^) {KState{a, z) D Holds{f, z)) 

iff \= (V^) mz) D Holdsif, z)) 

iff ^ ^(3^) ($(2) A -nHolds{f, z)) 

iff {$(z),-ffoJds(/,z)} h -L 
The proof of the second part is similar. □ 

This result is a formal justification of concluding knowledge of / if the constraint 
solver derives an inconsistency upon asserting state constraint -^Holds{f, z) under 
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state specification $(z). Figure shows how this is realized in FLUX by clauses 
for Knows{f, s) and Knows{^f , s) as well as for knowing a value of a fluent. More 
complex knowledge expressions, such as disjunctive knowledge, can be defined and 
encoded in a similar fashion. The clausal definition of KnowsVal{x , f , z) uses the 
auxihary predicate KHolds{f , z) , which matches the fluent expression / against 
all fluents that positively occur in state z. If so doing grounds all variables in x, 
then a value for these variables is known. 

Recall, for example, the FLUX state specification at the beginning of Sectional 
encoding state specification (|??|l- (|15|l . We can use FLUX to show that the robot 
knows that room (1, 3) is not occupied, while it does not know that office (1, 4) is 
free, nor that it is not so: 

?- zeta(Zeta) , 

knows_not(occupied(l,3) , Zeta) , 

\+ knows (occupiedCl ,4) , Zeta), 

\+ knows_not (occupiedCl ,4) , Zeta). 

yes. 

As an example for the FLUX definition of knowing a value, consider this incomplete 
state specification: 

init(ZO) :- 

Z0=[at(X,2) ,facing(2) |Z] , X#=l #\/ X#=2, duplicate_f ree (ZO) . 

The corresponding axiom in fluent calculus is 

KState{So, zq) = {3x, z) (zo = At{x, 2) o Facing(2) oz A [a; = 1 V x = 2]) 

It follows that Knows Vai(d, Facing((i), ^o) while -iKnowsVai((a;, ?/), At(a;, ?/), 5o) 
but KnowsVa\{y,At{x,y),Si^: 

?- init(ZO) , 

knows_val( [D] , f acing(D) , ZO) , 
\+ knows_val([X,Y] , at(X,Y), ZO) , 
knows_val( [Y] , at(_,Y), ZO) . 

D = 2 
Y = 2 

In theory, agents using the fluent calculus are logically omniscient. Therefore, the 
general problem of inferring knowledge under incomplete states is computationally 
demanding, if not undecidable in the flrst-order case. This is so because full the- 
orem proving is required to this end. The careful design of the state constraints 
supported in FLUX and the incomplete constraint solver, however, make the task 
computationally feasible. Since deciding unsatisfiability of a set of constraints is 
linear in the size of the constraint store, inferring knowledge in FLUX is linear in 
the size of the state description. 
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5.3 Knowledge update 

The frame problem for knowledge is solved in the fluent calculus by axiomatizing the 
relation between the possible states before and after an action (Thielscher 2 000)l . 
The effect of A{x), be it a sensing action or not, on the knowledge of the agent is 
specified by a so-called knowledge update axiom, ^ 

Knows{Poss{A{x)),s) D 

{3y){\Jz') [KState{Do{A{x), s), z') = (24) 
{3z){KState{s, z) A ^(z', z) A n(j7, 2', Do{A{x), s))) ] 

where specifies the physical state update while 11 restricts the possible states 
so as to agree with the actual state State{Do{A{x) , s)) on the sensed properties 
and values y. 

As an example, let the three actions of the cleaning robot be denoted by 

Clean : action empty waste bin at current location 
Turn : ACTION turn clockwise by 90° 
Go : ACTION move forward to adjacent square 
The action preconditions can be axiomatized as 

Poss{Clean, z) = T 
Poss{Turn,z) = T 
Poss{Go,z) = {\/d,x,y){Holds{At{x,y),z) AHolds{Facing{d),z) ^ ' 

D (3a;', y') Adjacent(x, y, d, x', y')) 
in conjunction with the auxiliary axiom 

Adjacent{x, y,d,x',y') = 1 < d < 4 A 1 < a;, x\ ?/,?/'< 5 A 

[d = lAx' = xAy' = y + lV 
d = 2Ax' = x + lAy' = yW (26) 
d = 3Ax' = xAy' = y- lW 
d = 4:Ax' = x- lAy' = y] 

That is to say, going forward requires the robot not to face the wall of the building 
while emptying a waste bin and making a quarter turn clockwise is always possible. 

The actions Clean and Turn of our cleanbot involve no sensing. The physical 
effects of these actions are specified by the following knowledge update axioms: 

Knows{Poss{Clean) , s) D 
[KState{Do{Clean, s), z') = 
{3z){KState{s,z) A 

(3a;, y) {Holds{At{x, y), z) A z' = z + Cleaned{x , y)) ) ] 

(27) 

Knows{Poss{Turn) , s) ^ 
[KState{Do{Turn, s), z') = 
(32) (KState(s,z) A 

(3rf) {Holds{Facing{d), z) A 

z' = z — Facing{d) + Facing{d-mod 4 + 1)) ) ] 

^ Below, the standard predicate Poss : ACTION X STATE denotes that an action is possible in a 
state. Macro Knows{Poss{a) , s) stands for the formula (Vz) {KState{s, z) D Poss{a, 2)). 
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Thus z' is a possible state after cleaning or turning, respectively, just in case z' 
is the result of cleaning or turning in one of the previously possible states z. 

The following knowledge update axiom for Go combines the physical effect of 
going forward with information about whether light is sensed at the new location: 

Knows{Poss{Go) , s) D 
[KState{Do{Go,s),z') = 
{3z){KState{s,z) A 

{3d, X, y, x', y') ( Holds{At{x, y), z) A 

Holds{Facing{d),z)A ^ ' 

Adjacent{x , y, d, x\ y') A 
z' ^ z- At{x, y) + At{x', y')) ) A 
[nuguiz') = nught{State{Do{Go,s)))]] 

where the sensed property indicates whether or not the robot perceives a light at 
its current location: 

^ughtiz) = i3x, y) {Holds{At{x, y), z) A Light{x, y, z)) (29) 

Thus axiom (^5)1 says that z' is a possible state after going forward if z' is the 
result of doing this action in some previously possible state and there is light at the 
current location in z' just in case it is so in the actual state State{Do{Go, s)). 

As an example of sensing a fluent value rather than a proposition, consider the 
specification of a location sensor. As a pure sensing action, self-location has no 
physical effect. In general, this is indicated in a knowledge update axiom by the 
sub-formula {3z) {KState{s, z)Az' — z) describing the (empty) physical effect. For 
the sake of compactness, this sub-formula has been simplified to KState{s, z') in 
the following axiom: 

Knows{Poss{SenseLoc) , s) D 

{3x, y){\fz') {KState{Do{SenseLoc, s), z') = (30) 
KState{s, z') A Holds{At{x, y), z') 

Put in words, there exist coordinates x,y such that the robot is at {x,y) in all 
possible states of the successor situation. (The foundational axiom for knowledge of 
Definition El fSection l5.1|l then implies that (.t, y) must also be the actual location 
of the robot.) 

5.4 Inferring knowledge update in FLUX 

Updating the knowledge state of a FLUX agent involves two steps, the physical 
effect and the sensing result of an action. Since knowledge states are identified with 
(incomplete) FLUX states as discussed in Section knowledge update according 
to the physical effect amounts to updating a FLUX state specification in the way 
discussed in Sectional Having inferred the physical effect of an action, agents need 
to evaluate possible sensing results as part of the update. To this end, the sensing 
outcome of an action is encoded by a (possibly empty) list of individual sensing 
results. The result of sensing a proposition is either of the constants True or 
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poss(clean, _) . 
poss(turn, _) . 
possCgo, Z) :- 

knows_val([X,Y] , at(X,Y), Z) , 

knows_val( [D] , facing (D) , Z) , 

adjacent(X, Y, D, _, _) , 

state_update(Zl, clean, Z2, [] ) :- 
holds (at (X, Y) , Zl) , 
updateCZl, [cleaned (X, Y) ] , [], Z2) . 

state_update(Zl, turn, Z2, [] ) :- 
holdsCf acing(D) , Zl) , 

(D#<4 #/\ D1#=D+1) #\/ (D#=4 #/\ Dl#=l), 
updateCZl, [facing(Dl)] , [facing(D)] , Z2) . 

state_update(Zl, go, Z2, [Light]) :- 
holds (at (X, Y) , Zl) , 
holdsCf acing(D) , Zl) , 
adjacent (X, Y, D, XI, Yl) , 
updateCZl, [at(Xl,Yl)], [at(X,Y)], Z2) , 
light (XI, Yl, Light, Z2) . 

adjacent(X, Y, D, XI, Yl) :- 

[X,Y,X1,Y1] : : 1. .5, D : : 1. .4, 

(D#=l) #/\ (X1#=X) #/\ (Y1#=Y+1) y. north 



Fig. 7. FLUX encoding of the precondition and update axioms for the clcanbot. 



False. The result of sensing a value is a ground term of the respective sort. For 
example, the sensing result for knowledge update axiom (|28|l is encoded by [tt] 
where tt g {True, False}, depending on whether light is actually sensed at the new 
location. The sensing result for knowledge update axiom (|30|l . on the other hand, 
should be encoded by [x, y] where x,y : N. 

Based on the notion of sensing results, knowledge update axioms are encoded in 
FLUX as definitions of the predicate StateUpdate{zi, A{x), Z2, y) describing the 
update of state zi to Z2 according to the physical effects of action A{x) and the 
sensing result y. As an example. Figure [3 depicts a FLUX encoding of the action 
precondition and knowledge update axioms for the cleaning robot domain. Neither 
Clean nor Turn provides any sensor data. The sensing result for action Go is 
evaluated with the help of the auxiliary predicate Light as defined in Section |31 

Consider, for example, the initial FLUX state for the cleaning robot shown in 



#\/ 

(D#=2) #/\ (X1#=X+1) #/\ (Y1#=Y) 
#\/ 

(D#=3) #/\ (X1#=X) #/\ (Y1#=Y-1) 
#\/ 

(D#=4) #/\ (X1#=X-1) #/\ (Y1#=Y) 



y, east 



y, south 



y, west 
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init(ZO) :- 

ZO = [at(l,l) ,facing(l) I Z] , 
not_holds(occupied(l , 1) , Z) , 

not_holds(occupied(2, 1) , Z) , 7. hallway 

not_holds(occupied(4,5) , Z) , 
consistent (ZO) . 

consistent (Z) :- 

holds (at (X, Y) , Z, Zl) , [X,Y] :: 1 
holds (facing (D) , Z, Z2) , [D] :: 1 
not_holds_all (occupied (_, 0) , Z) , 
not_holds_all(occupied(_,6) , Z) , 
not_holds_all(occupied(0,_) , Z) , 
not_holds_all(occupied(6,_) , Z) , 
duplicate_f ree (Z) . 

Fig. 8. Initial state specification for the cleanbot domain. The clause for 
Consistent{z) specifies general domain constraints, such as uniqueness of the 
robot's position and orientation. 



Figure |H1 Suppose that when going north twice, the robot senses no light after 
the first action but after the second one. With the following query the cleanbot 
computes the knowledge update for this sequence of actions and the given sensing 
results: 

?- init(ZO), state_update (ZO , go, Zl, [false]), 
state_update (Zl , go, Z2, [true]). 

ZO = [at(l,l) ,facing(l) I Z] 
Zl = [at(l,2) ,facing(l) I Z] 
Z2 = [at(l,3) ,facing(l) I Z] 

Constraints : 

not_holds (occupiedd , 3) , Z) 

or_holds( [occupied(2 , 3) , occupiedd ,4)] , Z) 

Thus the agent has evaluated the acquired sensor data and inferred its actual po- 
sition according to the physical effects of Go. 

As an example for inferring the update when sensing a value of a fluent, consider 
the following FLUX clause, which encodes knowledge update axiom H30|l for action 
SenseLoc: 

state_update (Z , sense_loc, Z, [X,Y]) :- holds (at (X, Y) , Z) . 

That is, no physical effect affects the state but the sensed value is incorporated 
into the specification. Suppose, for instance, the agent is uncertain as to whether it 



..5, not_holds_all(at(_,_) , Zl) , 
..4, not_holds_all(facing(_) , Z2) , 
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moved north or east from its initial location (1, 1), while the subsequent position 
tracking reveals that it is at (1,2): 

init(ZO) :- ZO = [at (1 , 1) ,f acing(D) | _] , D#=l #\/ D#=2, 
consistent (ZO) . 

?- init(ZO), state_update(ZO, go, Zl, [false]), 

state_update(Zl , sense_loc, Z2, [1,2]). 

ZO = [atd.D ,facing(l) I Z] 
Zl = [at(l,2) ,facing(l) | Z] 
Z2 = [at(l,2) ,facing(l) | Z] 

Constraints : 

not _holds (occupied (1, 3) , Z) 

Thus the agent has inferred its actual position and, hence, concluded that it is 
actually facing north. Incidentally, knowing the location also allows to infer that 
office (1,3) is not occupied, which follows from the observation that no light is 
sensed after the Go action. 

5.5 Defining knowledge update for actions with conditional effects 

FLUX agents rely on knowledge update axioms in order to maintain their internal 
model of the environment. As this model is usually incomplete, the update axioms 
need to be carefully encoded in FLUX so as to always lead to a correct resulting 
knowledge state. In particular, when specifying an action with conditional effects 
the programmer needs to define the correct update for any possible knowledge the 
agent may have concerning the fluents affected by the action. Consider, for example, 
the action Alter {x) to alter the position of a toggle switch. If x happens to be open 
(fluent Open{x)), then it will be closed afterwards (i.e., not Open); otherwise, i.e., 
if it is c;loscd beforehand, then it will be open after the action. Tacitly assuming 
that the action is always possible, its conditional effect is specified in the fluent 
calculus by the following knowledge update axiom: 

KState{Do{Alter{x),s),z') = 

{3z) ( KState{s, z) A [Holds{Open{x) , z) Az' = z — Open{x) , . 

V ^ ^ 

-'Holds{Open{x) , z) A z' = z + Open{x) ] ) 

The FLUX encoding of this update axiom requires to distinguish three kinds of 
knowledge states. In case the current knowledge entails that switch x is open, 
the resulting knowledge state is obtained through updating by negative effect 
^Opcn(x). Conversely, in case the current knowledge entails that switch x is not 
open, the resulting knowledge state is obtained through updating by positive effect 
+ Open{x). Finally, if the current knowledge state does not entail the status of the 
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switch, then this uncertainty transfers to the updated knowledge state. Moreover, 
possible partial (e.g., disjunctive) information regarding the position of the affected 
switch is no longer valid and, hence, needs to be cancelled. 

state_update(Zl, alter (X), Z2, [] ) :- 

knows ( open (X) , Zl) -> update(Zl, [], [open(X)] , Z2) ; 

knows_not (open(X) , Zl) -> update(Zl, [open(X)] , [] , Z2) ; 
cancel(open(X) , Zl, Z2) . 

For example, 

?- not_holds(open(tl) , ZO) , 

or_holds ( [open(t2) , open(t3) ] , ZO) , 
state_update(ZO, alter (tl), Zl, [] ) , 
state_update(Zl, alter (t2), Z2, [] ) . 

Z2 = [open(tl) I ZO] 

Constraints : 

not_holds (open(tl) , ZO) 

That is to say, while switch Ti is known to be open after altering its position, it 
no longer follows, after altering T2 , that T2 or T3 is open. ^ 

6 A FLUX control program for the cleaning robot 

In this section, we show how our LP-based approach to reasoning about actions 
can be used as the kernel for a high-level programming method for the design of 
agents that reason about their actions. These agents use the concept of a state as 
their mental model of the world when controlling their own behavior. As they move 
along, agents constantly update their world model in order to reflect the changes 
they have effected and the sensor information they have acquired. Thanks to the 
extensive reasoning facilities provided by the kernel of FLUX and in particular the 
constraint solver, the language allows to implement complex strategies with concise 
and modular programs. 

The general architecture of FLUX agent programs is depicted in Figure 1^1 Every 
agent program contains the kernel Pkcmci , which consists of 

^ Actually, the inferred knowledge state in this example is slightly weaker than what is implied by 
knowledge update axiom I31i . Suppose that initially T2 or T3 is open. Then it follows that 
after altering the position of T2 , if T2 is open then so is T3 ! This is so because if T2 is open 
after changing its position, it must have been closed initially, and hence T3 was (and still is) 
open. The corresponding implication, i.e., HoJds(Open( T2), ^2) 3 Hoids(Open( T3), 22) 1 is not 
entailed by the updated FLUX state. Fortunately, obtaining a weaker update specification — ^just 
like an incomplete inference engine — is not an obstacle towards sound agent programs. Since 
FLUX agents are controlled by what they know of the environment, a sound but incomplete 
knowledge state suffices to ensure that the agent draws correct conclusions. This is a consequence 
of the simple fact that everything that is known under a weaker knowledge state is also known 
under the stronger one. 
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Pstratcgy 



domain 



^kernel 



Fig. 9. The three components of FLUX agent programs. 



• the FLUX constraint system of Figure 13 and |21 plus a constraint solver for 
finite domains; 

• the definition of update of Figure ^ and |31 

• the definition of knowledge of Figure and 

• the following definition of execution, by which action a is performed and, 
simultaneously, the current state zi is updated to state 22 according to the 
effects and sensing result of performing a : 

executeCA, Zl, Z2) :- 

perform(A, Y) , state_update (Zl , A, Z2, Y) . 

The second part, Pdomain, of a FLUX agent program contains encodings of the 
domain axioms. These include 

• action precondition axioms, 

• update axioms, 

• domain constraints, and 

• initial knowledge state. 

The domain program for the cleanbot, for example, consists of the precondition 
and update axioms of Figure along with the initial knowledge state and domain 
constraints of Figure |H1 

On top of this, the programmer defines the intended behavior of the agent via a 
control program Pstratcgy- This program uses the basic predicate Execute{zi, a, Z2) 
for the execution of an action. To this end, the interaction of the agent with the 
outside world needs to be defined by the predicate Perform{a, y), which causes the 
physical agent to carry out action a in the environment such that y returns the 
sensing information acquired by performing this action. Control programs Pstrategy 
use the predicate Knows{f,z) (and its derivatives KnowsNot and Knows Vai) to 
evaluate conditions against the internal world model. 

Figure 1101 depicts a sample control program for our cleaning robot. After the 
initialization of the world model and the execution of a Clean action at the home 
square, the main loop is entered by which the robot systematically explores and 
cleans the office floor. To this end, the program employs two parameters containing, 
respectively, choice points yet to be explored and the current path of the robot. The 




'domain 



'state 
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main : - 

init(ZO) , 

execute (clean, ZO, Zl) , 

Choicepoints = [[1,2,3,4]], Backtrack = [] , 
main_loop(Choicepoints , Backtrack, Zl) . 

main_loop( [Choices I Choicepoints] , Backtrack, Z) :- 
Choices = [Direction I Directions] -> 
( go_in_direction(Direction, Z, Zl) 
-> execute (clean, Zl, Z2) , 

Choicepointsl = [[1,2,3,4], Directions I Choicepoints], 
Backtrackl = [Direction I Backtrack] , 
main_loop (Choicepointsl , Backtrackl, Z2) 

* 

main_loop( [Directions I Choicepoints] , Backtrack, Z) ) 

backtrack (Choicepoints , Backtrack, Z) . 

go_in_direction(D, Zl, Z2) :- 

knows_val([X,Y] , at(X,Y), Zl) , 
adjacent(X, Y, D, XI, Yl) , 
\+ knows(cleaned(Xl,Yl), Zl) , 
knows_not(occupied(Xl,Yl) , Zl) , 
turn_to_go(D, Zl, Z2) . 

backtrack(_, [] , _) . 

backtrack (Choicepoints, [Direction | Backtrack] , Z) :- 
Reverse is (Direction+1) mod 4+1, 

turn_to_go (Reverse , Z, Zl) , 

main_loop (Choicepoints , Backtrack, Zl) . 

turn_to_go (D , Zl, Z2) :- 

knows(facing(D) , Zl) -> execute(go, Zl, Z2) 

execute(turn, Zl, Z) , turn_to_go(D, Z, Z2) . 
Fig. 10. A cleanbot agent in FLUX. 



latter is used to backtrack from a location once all choices have been considered. 
A choice point is a list of directions, which are encoded by 1 (for north) to 4 (for 
west) as usual. The path is represented by the sequence, in reverse order, of the 
directions the robot took in each step. 

In the main loop, the cleanbot selects the first element of the current choices. If 
the attempt to go into this direction is successful (predicate GoInDirection), then 
the robot empties the waste bin at the new location. A new choice point is created, 
and the backtrack path is augmented by the direction into which the robot just 
went. If, on the other hand, the chosen direction cannot be taken, then the main 
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loop is called with a reduced list of current choices. In case no more choices are left, 
the cleanbot backtracks (predicate Backtrack). 

The auxiliary predicate GoInDirection{d , zi , Z2) succeeds if the cleanbot can 
safely go into direction d from its current location in state zi , ending up in state Z2 ■ 
A direction is only explored if the adjacent square is inside of the boundaries. 
Furthermore, this location must not have been visited already (that is, it is not 
known to be cleaned), and — most importantly — the adjacent location must known 
not to be occupied. By the auxiliary predicate Backtrack, the robot takes back one 
step on its current path by reversing the direction. The program terminates once 
this path is empty, which implies that the robot has returned to its home after it 
has visited and cleaned as many locations as possible. The two auxiliary predicates 
GoInDirection and Backtrack in turn call the predicate TurnToGo, by which the 
robot makes turns until it faces the intended direction, and then moves forward. 

The following table illustrates what happens in the first nine calls to the main 
loop when running the program with the initial state of Figure |S1 and the scenario 
depicted in Figure 



At 


Choicepoints 




Backtrack 


Actions 


(1,1) 


[[1,2,3,4]] 


[] 


GC 


(1,2) 


[[1,2,3,4] , 


[2,3,4]] 


[1] 


GC 


(1,3) 


[[1,2,3,4] , [2,3,4] , 


[2,3,4]] 


[1,1] 




(1,3) 


[[2,3,4] , [2,3,4] , 


[2,3,4]] 


[1,1] 




(1,3) 


[[3,4] , [2,3,4] , 


[2,3,4]] 


[1,1] 




(1,3) 


[[4] , [2,3,4] , 


[2,3,4]] 


[1,1] 




(1,3) 


[[] , [2,3,4] , 


[2,3,4]] 


[1,1] 


TTG 


(1,2) 


[[2,3,4] , 


[2,3,4]] 


[1] 


TTTGC 


(2,2) 


[[1,2,3,4] , [3,4] , 


[2,3,4]] 


[2,1] 


TTTGC 



The letters G, C, T are abbreviations for the actions Go, Clean, and Turn, re- 
spectively. After going north twice to ofhce (1,3), the cleanbot cannot continue 
indirection 1 or 2 because both office (1,4) and office (2,3) may be occupied 
according to the robot's current knowledge. Direction 3 is not explored since lo- 
cation (1,2) has already been cleaned, and direction 4 is ruled out as (0,3) is 
outside of the boundaries. Hence, the cleanbot backtracks to (1,2) and continues 
with the next choice there, direction 2, which brings it to location (2,2). From 
there it goes north, and so on. Figure ITTI depicts the knowledge state at the time 
the program terminates. Back home, the cleanbot has acquired knowledge of all 
four occupied offices. Moreover, it has emptied all waste bins but the ones in these 
four offices and the bin in office (5, 1). This office has not been visited because the 
robot cannot know that it is not occupied — the light sensors have been activated 
at both surrounding locations, (4,1) and (5,2)! 
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1 2 3 4 5 



Fig. 11. The final knowledge state in the cleaning robot scenario. The small circles 
indicate the cleaned locations. 



6. 1 Semantics of FL UX programs 

The semantics of a FLUX agent program is given as a combination of the fluent 
calculus and the standard semantics of logic programming. We assume the reader to 
be familiar with the basic notion of a computation tree for constraint logic programs 
(see, e.g., Ij.Taffar and Maher 19941 1). 

Let T be the computation tree for an agent program Pstratcgy U Pdomam U Pkernei 
along with a query {<— Q}. Tree T determines a particular action sequence as fol- 
lows. Let an execution node be any node in T which starts with the atom Execute. 
Let Execute{ai, _,_), Execute{a2, -,-),■■ ■ be the ordered sequence of all execu- 
tion nodes occurring in T, then this tree is said to generate the action sequence 
ai, a2, . . . This sequence is to be used when proving formal properties of the agent 
program with the help of the fluent calculus and the axiomatization Tidomain of 
the application domain. For example, a program can be called sound if the domain 
axiomatization entails that all actions are possible in the situation in which they 
are executed. Formally, 

Estate U Edomam h Poss{ai, Sq) A Poss{a2, Do{ai, Sq)) a... 

Domain-dependent requirements are proved in a similar fashion. The program 
for the cleanbot, for example, can be shown to admit a finite computation tree; 
hence to terminate. Other properties are that the cleanbot will always end up in 
its home (1,1), it will never enter an office which is occupied (provided its light 
sensor functions correctly), and it always cleans all locations in the hallway. The 
formal proofs of these properties are not deep but tedious, which is why we refrain 
from giving them here. 

6.2 Computational Behavior 

To illustrate the computational merits of FLUX, we have compared it to GOLOG 
ULevesque et al. 1997| l, an agent programming language with similar purposes. The 
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Fig. 12. Experimental results with the cleanbot control program in FLUX and 
GOLOG. (Notice the exponential scale on the vertical axis.) 



cleanbot domain requires a variant of GOLOG which supports incomplete states 
and sensing IjReiter 2001h|l . In this system, incompletely specified initial situations 
are encoded by sets of (propositional) prime implicates. To decide whether a prop- 
erty is known to hold after a sequence of actions, the property is regressed to the 
initial situation. If the resulting formula is entailed by the initial prime implicates, 
then the original property is known to hold in the respective situation. Acquired 
sensor information is regressed, too, and the result is added to the initial set of 
prime implicates. 

We have re-implemented the strategy of Figure nTH for the cleanbot as a GOLOG 
program and ran a series of experiments with square office floors of different size. 
For simplicity, no initial information about unoccupied cells besides (1,1) and the 
two adjacent ones were given to the robot. Figure El depicts the results of five sets 
of experiments. The given runtimes (seconds CPU time of a 1733 MHz processor) 
are the average of 10 runs with randomly chosen occupied cells. 

The dominance of FLUX has two main reasons: 

1. Since prime implicates can be used to encode arbitrary propositional formulas, 
the complexity of inferring knowledge in the GOLOG system of IjReiter 2001b|l 
is exponential. In contrast, the restricted first-order state representation and 
the incomplete inference engine of FLUX allows for inferring knowledge in 
linear time. 

2. In FLUX, the world model is progressed whenever an action is performed, 
and the new model is directly used to decide whether a property is cur- 
rently known. The GOLOG system of l|Reiter 2001b,l . on the other hand, is 
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Fig. 13. Growth of the action selection time as the execution of the cleanbot pro- 
gram proceeds (averaged over 10 runs with 6x6 rooms). 



regression-based, so that deciding whether a property is known in a situation 
requires to regress the property through the previously performed actions. 
Consequently, the computational behavior of the GOLOG program worsens 
the longer the program runs. This can be clearly seen from the graphs in Fig- 
ure El which depict the average time for action selection at different stages 
of the execution of the cleanbot program. 
3. To solve the frame problem, FLUX uses state update axioms, which specify 
the effects of an action on an entire state. When progressing a state through 
an update axiom, the large body of unaffected knowledge simply remains in 
the constraint store. This is what makes up an efficient solution to the frame 
problem even in the presence of incomplete states. 



7 Discussion 

We have presented the logic programming method FLUX for the design of logically 
reasoning agents. The agents use a system of Constraint Handling Rules and finite 
domain constraints to reason about actions in the presence of incomplete states. 
Both the constraint solver and the logic program for state update have been formally 
verified against the action theory of the fluent calculus. Thanks to a carefully chosen 
expressiveness, the FLUX kernel exhibits excellent computational behavior. 

The closest related work is the programming language GOLOG ( |Levesque et al. 1997| l 
for dynamic domains, which is based on the situation calculus and successor state 
axioms as a solution to the frame problem l|Reiter 1991|l . The main differences are: 
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1. GOLOG defines a special programming language for strategies, while FLUX 
strategies are standard logic programs. 

2. With the exception of IjR.eiter 2001b|l . existing implementations of GOLOG 
apply the principle of negation-as-failure to state specifications and, hence, 
are restricted to complete state knowledge and deterministic actions. With 
its underlying constraint solver, FLUX provides a natural way of representing 
and reasoning with incomplete states as well as nondeterministic actions. 

3. The logic programs for GOLOG described in the literature all apply the prin- 
ciple of regression to evaluate conditions in agent programs. While this is 
efficient for short action sequences, the computational effort increases with 
the number of performed actions. With the progression principle, FLUX pro- 
grams scale up well to the control of agents over extended periods. ^ Moreover, 
progression through state update axioms in FLUX provides an efficient solu- 
tion to the frame problem, because unaffected state knowledge simply remains 
in the constraint store. 

4. GOLOG includes the concept of nondeterministic programs as a means to 
define a search space for a planning problem. To find a plan, such a program 
is executed "off-line" with the aim to find a run by which the planning goal 
is attained. A similar concept can be added to FLUX, allowing agents to 
interleave planning with program execution fThiclschcr 2002). 

We are conducting experiments where FLUX is applied to the high-level con- 
trol of a real robot, whose task is to collect and deliver in-house mail in an of- 
fice floor l|Fichtner et al. 20'?l3jl . To this end, the logic programming system has 
been extended by a solution to the qualification problem ( [McCar thy 1977|) in the 
fluent calculus which accounts for unexpected failure of actions ( Thielsch er 20011 
IMartin and Thielscher 200 l|l . Future work will include the gradual extension of the 
expressiveness of FLUX, e.g., by constraints for exclusive disjunction, without loos- 
ing the computational merits of the approach. 
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